1. Field of Invention
The present invention relates to the field of process management of a workflow environment on computer systems and the field of computerized transaction processing. More particularly, the invention relates to the area of computerized transaction execution with a workflow management systems (WFMS).
2. Definitions
The following definitions of acronyms used throughout the specification may be useful in providing a better understanding of the subject matter of the present invention:
2PC: Two-Phase-Commit Protocol PA1 ACP: Atomic Commit Protocol PA1 DTS: Distributed Transaction Services PA1 ISO: International Standard Organization PA1 ODA: Object Definition Alliance PA1 OMG: Object Management Group PA1 OTS: Object Transaction Services PA1 TM: Transaction Manager PA1 TP: Transaction Processing PA1 WfMC: Workflow Management Coalition PA1 WFMS: Workflow Management System PA1 XID: Transaction Identification PA1 1. let their customers specify groupings of activities which will have the property that either all activities of the grouping have performed transactionally successful (i.e. its changes on recoverable objects have been committed or were identified to be omitted from transaction completion based on the actual workflow) or all have been aborted; and PA1 2. manage such groupings at run time in such a way that the above operational behavior is enforced.
A transactional work item, or transaction in general, are not to be construed to be limited to a local or distributed transaction. Accordingly, a transaction may be of any of these types. Moreover, when referring generally to a transaction, the textual context will define if a general concept is meant or if a transactional work item as a specific embodiment of a transaction is denoted.
While concentrating on transactional work items being activities within a process model, any number of additional (non-transactional) activities can be part of a process model which will not be referenced explicitly.
Transactional application, hereafter transaction, comprises a sequence of operations that change recoverable resources and data, such as a database, from one consistent state into another. A transaction processing system guarantees that if a transaction executes some updates against recoverable resources and data, and if a failure occurs before the transaction reaches its normal termination or an interim point of consistency, then those updates will be undone (rollback). When a new point of consistency has been reached and all updates made by the transaction must be made permanent, the transaction commits.
To fulfill this transaction recovery guarantee, the system must be able to remember across system outages both transactions in progress and their update actions, so that their effect on recoverable data can be properly reflected when the system is restarted. In general, the system maintains a log, recorded and maintained by a log manager, of each transaction's progress and changes to the resources and data in order to fulfill the transaction recovery guarantee. The log data, known as log records, can be examined to ensure that either the transaction's committed actions are reflected in the database or were undone. When the log records include actual data, they can also be used to reconstruct data which has been damaged or lost, such as by the failure of a storage device. The log can be thought of as an ever growing sequential file.
The log is permanently stored on stable storage, such as a disk file, which remains intact and available across system failures. Log records are first written to temporary, volatile log file buffers in the computer's memory, and then transferred to stable storage at certain times (e.g., when a transaction is committed).
Locking, supported by a lock manager, is used to control simultaneously executing (i.e. concurrent) transactions' access to shared resources and shared data, and in particular is used to prevent concurrent transactions from inconsistently modifying the same resources and data. Appropriate use of locking can guarantee a transaction that the resource it manipulates and the data it reads is in a consistent state and that the resource and data does not contain uncommitted updates of other transactions.
The recoverable resources and data the transaction is manipulating further may be supported by a resource manager. A resource manager is a subsystem that manages transactional objects of a certain type. The resource manager typically offers services to applications or other resource managers, which might be available in the overall system. Many transaction based elements can act as resource managers, for example a transactional database system, a transaction queue manager, a transactional session manager.
A transaction manager administrates, manages and coordinates the flow of the multitude of concurrently processing transactions through the computer system. It orchestrates the commit and undo, i.e. rollback, of transactions, as well as the recovery of objects, resource managers or sites after they fail.
The above mentioned consistency requirement for a certain transaction and for all other concurrently processing transaction in the local or distributed transaction system is expressed as the ACID requirement. Actually ACIDicity is a combination of four different sub-requirements:
Atomicity
A transactions' changes to the state of the overall system are atomic; either all happen or none happen. These changes include all changes to resources including database changes, messages, actions on transducers and so forth.
Consistency
A transaction is a correct transformation of the system state. The actions taken as a group do not violate any of the integrity constraints associated with the state. This requires that the transaction be a correct program.
Isolation
Even though transactions execute concurrently, it appears to each transaction T, that other transactions execute either before T or after T, but not both. Therefore intermediate states of one transaction are not visible to the other transactions.
Durability
Once a transaction completes successfully and it commits its activities, its changes to the state survive failures, i.e. the state changes became permanent.